vaultofthearchonfandomcom-20200214-history
119647-development-process-question
Content ---- ---- ---- Can't do that. Then you'd complain that they never say anything or tell us what is coming before the patch. Transparency is tricky, but we're FAR better off hearing from the devs who make the fixes, even if it is weeks before it makes it through the QA and testing process. ESPECIALLY when we're talking about a backup fix for something they thought they'd already fixed. The process begins over again from zero because obviously the first solution didn't work on the entire problem. | |} ---- :D This actually made me LOL. | |} ---- ---- You clearly didn't play Swtor at launch then. FYI they changed from monthly to quarterly after they released the so called "damaged" product. Drop 3 has it's issues, but it's hardly damaged....well for the most part :D I get people's frustration. I, myself am having a really annoying problem with WS at the moment which no work around seems to be fixing, but would you rather them continue on like everything is fine and dandy and do monthly releases which are even more "broken than the quarterly ones? They aimed to have monthly content and thought they could do it. They were wrong. You can't change a companies business model over night and expect everything to be perfect. The crowd that WS has attracted seems to be not what they expected at all. More RP'ers and casual players have come on board even though the game was advertised as a HC game. They are having to re-think and essentially re-develop their entire plans. I work for a tiny 20 man company. When we make changes it takes weeks and weeks of planning. Then weeks of testing and then get it through regulation etc etc. Imagine how long this takes for a large company to do? I'm not intending on trending on people's toes nor am i being an intentional "white knight", but Carbine are new to the MMO world and are learning the hard way on how to go about it. Sadly this takes time and patience which I appreciate isn't a luxury. | |} ---- ---- ---- Wasn't sabotage totally broken though and that started all the changing of how they would introduce things | |} ---- it didn't break anywhere near as bad as Drop 3. In Drop 3 everything broke. LAS broke, ability to change abilities or action bars broke, housing harvesting plots broke, NPCs that take you to zones broke... IT was near unplayable for days and still very annoying for a week or two. | |} ---- You will be suprises. Simple google for carbine jobs and read, what they are asking for. e.g.: "Desire/ability to work in a team environment" Seems, they never heared the word "agile". | |} ---- I stand corrected then | |} ---- that's required for agile as well. I'm in uni and year 1 we did waterfall, year 2 we did agile. Both have to do with working in a team based environment. The only difference is that agile has daily meetings, daily scheduling (and re-schedulling the next day depending on what you did the previous day), involving testers from as early in planning as possible and going trough a constant feedback -> concept loop. | |} ---- If you only implemented those few elements, then you did not realy accomplish agile development. Agile development is much more than doing some dailies. This is one of the major misconceptions, where companies switch to "agile" and wonder, why nothing gets better. Perhaps I better should have talked of "Agile Productmanagement" Perhaps you read here: http://www.romanpichler.com/ | |} ---- you switch a lot by going in loops, rather than building everything from one Bible, until you reach the end and wonder why it doesn't sit well with the audience. And even what you're talking about still involves working in groups: Working as an effective product managers or product owner requires vision and leadership skills. You should be able to establish a shared vision, set realistic goals, and describe the benefits your product should deliver. You should be able to actively listen to others and negotiate to reach agreement and get buy-in. there's no such thing as "I work solo and everybody should do it my way" that works well. | |} ---- ---- ---- Wait, what? There was only one actual game crashing bug, which probably existed before drop 3 and only became an issue because a character with bad data was trying to log in again. I'm not saying that drop 3 was perfect, but there's no need to blow things out of proportion like that. Or like this. I started at my current job just as a big government contract was switching over to "agile" from waterfall. I use the quotes, because its hard to call a two month sprint agile. But somehow everything got back on track, so even bad agile can be an improvement if you're starting from something even worse. | |} ---- Large projects that are "difficult to work with" are destined for failure. A clear and clean code base is attainable regardless the overall complexity and the amount of developer churn it has experienced. More important it is essential for future scalability and maintainability. That said, it wouldn't surprise me in the least that they're fighting the Flying Spaghetti Monster. Regressions, yo. | |} ---- As an Agile Coach....that's bullshit. Just cause you're agile doesn't mean you get to shove stuff to the side. Agile means being flexible enough to actually meet deadlines and focus on what's important.... | |} ---- ---- ---- ---- Yes if it's done properly and as I said in reality a lot of the time it's not. It was tongue in cheek anyway about moving deadlines. Certainly when people are trying to adopt it when they don't have the foundations set for it. | |} ---- From experience, people often try to adopt something they understand only half, or do it for the wrong reasons. Other problems I often encounter when introducing Agile somewhere is the fear of change, or middle/upper management not having a clue why they need the change. You'd be surprised how much people sabotage their own work and colleagues just out of fear for changing something. Teams that do pull it off, you see them grow on a daily basis, tackling new problems better and faster. Funny thing is that this "agile" methodology is rather old in the industry, but that IT is only picking it up since the last 10 years. | |} ---- Full agreement. And it happens (I suppose not rarely) , that the companie's senior is the one, who starts sabotaging. | |} ---- ---- Hi Lusalot, I'm going to break down your questions and answer them as best as I can. Why does it take so long to get little fixes out? Our internal environments in their current capacity look like the following: Development | Staging | PTR Unlocked | PTR Mirror | Live Mirror Our external public facing environments look like the following: PTR | Live Any feature development or bug fix must be checked into an environment in order for the change to take effect. A "build" of the game server and clients must then take effect for our internal devs to verify that the change was made. In the case of a bug on Live, we have to check the fix into Live Mirror and all of those environments that fall below it. We have tools that allow us to reduce the overhead of checking in across all environments, but we still have to assess every live bug and determine from a change management perspective how risky the fix is and the scope of QA time required to test it. Based on an objective severity rating and taking into account subjective opinions from our community and developers, we triage out issues to determine which environments they should be fixed in and when their intended deployment will occur. Once an issue is fixed and a build has been provided, it passes to our QA and Release Management team. The goal of these teams are to perform smoke tests, full regression testing, and BVTs on the builds that are created. If a build passes these tests and all of the necessary certifications have occurred with the Release Management team, a time is scheduled for deployment to Live, patch notes are generated, and the build is pushed to the public PTR or Live environment. Between bug fix, triage, build, QA, and release there are a lot of moving pieces and dozens of teams that need to verify, approve, and release the content, resulting in sometimes delayed or longer than liked release windows. Why does development take so long and why are there bugs in content? Development of new features requires a lot of studio buy in and resource commitment to begin. The scope of features is often huge and they must proceed through four distinct phases: Pre-Production (the early design documents are drafted and discussions about the philosophy or goal of the feature are had) Prototype (an early playable working prototype is created) Production (the full commitment of asset creation, engineering efforts, etc. are done for the feature) Post-Production / Polish (this is very much the polish phase of a feature, where remaining UX bugs are triaged, fixed, etc.) Once these phases are complete, the feature has to make its way through rigorous QA and Release Management processes. We have a certification process where we attempt to identify and fix many of the critical issues associated with a feature. Once the QA and Release certification process is complete, we are ready to deploy the feature in our quarterly patches. In our current capacity, we run continuous integration against multiple development environments with multiple development builds per week. Moving forward, in order to better embrace Agile practices and to reduce the risk associated with large scale CI on new features, we will be moving to a code trunk. Why are deadlines broken? Historically we did pretty well with hitting our release cadences, this can be noted for Drop 1 and Drop 2 which both went out as planned. Unfortunately, as we found and so did players, the quality of our release were not high enough. Internalizing player feedback we made the decision to move away from monthly releases in order to better provide the end to end testing required for a quality product and to empower all of our teams to fix and identify major issues in their content. In our current capacity, I am very optimistic that our future development velocity will increase, unfortunately, as many teams know, when changing processes a huge reduction in velocity occurs. We are at this stage currently and I am hopeful that by early next year we will see studio wide increases as we better adapt to the changes we have implemented. Does Carbine use Agile Scrum? Yes and no. We approach project management with a tool set. We look at teams and we see that Agile Scrum works great for some of them and that Kanban or even Waterfall works better for others. I see ourselves adopting more and more Agile methodologies as we move into the New Year and I am hopeful that a lot of the principles that are core to Agile have a grassroots growth at Carbine. A great example of this is a blending of eXtreme Software Development and Scrum on some of our Engineering teams. They firmly enforce paired programming and code reviews and in addition to this are able to voice blocker issues or discuss cross feature/disciplinary issues during their daily standups. In conclusion, I think we are making huge strides towards the Agile Manifesto: Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan More importantly, I think we are making strides towards the core Agile Principles as well: Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Continuous attention to technical excellence and good design Simplicity—the art of maximizing the amount of work not done—is essential Self-organizing teams Regular adaptation to changing circumstances The truth is that we aren't there yet, but we are committed in making a huge effort in trying to get there. While all of these changes aren't easy to implement across an entire organization, it's the ability to iterate and apply the toolsets we have at our disposals that we will continue to rely on to increase efficiency and value for our players. Cheers Edited December 12, 2014 by Virtue | |} ---- ---- ---- Programming is difficult to begin with. Throw in the complexity of an MMORPG and that compounds the problem 10 fold. It's a juggling act and even the smallest tweets can have far reaching effects that no one can predict. I'd rather then take their time to get patches right than crank them out fast and cause serious problems. | |} ---- This actually explains quite a bit. Good on your team for being flexible. My last architecture gig was with a company that hadn't changed process since the 80s. That didn't work so well in the Revit world. So it's good that you guys recognized the complaints from players saying the process was broken and decided that it's not just the game that could use fixes, but the process itself. Here's hoping you guys get your speed up. If you release Drop 4 in January, you'll have accelerated by nearly a month from your last drop's development cycle. | |} ---- I didn't experience any issues that made the game unplayable to me. The only things I even noticed were harvest nodes and LAS swapping... but I use a third party addon for LAS swapping anyways so it didn't affect me. | |} ---- ----